1. Technical Field
The present invention relates to mobile telecommunications and, more particularly, to an operational state in which a user equipment (UE) simultaneously has radio links with two or more radio access network (RAN) access points.
2. Discussion of Related Art
In the third generation partnership project (3GPP), to support mobility in the Universal Terrestrial Radio Access Network (UTRAN) a Serving Radio Network Subsystem (SRNS) relocation procedure has been defined by 3GPP Technical Specification Group (TSG) Radio Access Network (RAN) Working Group 3 (WG3). With the aid of this procedure the UTRAN can transfer the active Radio Resource Control (RRC) connection from one Radio Network Controller (RNC) (Source RNC) to another (Target RNC).
The triggering of the SRNS relocation procedure is dependent on the mobility of the UE. If the UE camps on a cell that is not controlled by the current Serving RNC the UE should send either a Cell or User Registration Area (URA) update message (which one is dependent on the network configuration). Based on this message the RNC may trigger the SRNS relocation procedure, which means that the RRC connection will be changed from this RNC (Source RNC) to the new RNC (Target RNC). The target RNC will after the successful SRNS relocation act as a new Serving RNC. During the SRNS relocation procedure all necessary signalling information and all user plane data will be transferred to the target RNC, to enable the target RNC to establish the same radio bearers (RBs) in the target RNC as were used in the source RNC and to ensure that the new Serving RNC can continue the data transmission from any service data unit (SDU), which has not yet been acknowledged by the UE.
The radio bearer re-establishment in the target RNC concerns both signalling plane and user plane RBs. For each RB the new Serving RNC should allocate such layer 2 (L2) resources (i.e., for Medium Access Control (MAC) and Radio Link Control (RLC) entities), which are as identical as possible with the resources in the old Serving RNC. The re-establishment is always made by using the received configuration parameters from the old Serving RNC. These parameters identify the characteristics of each RB; however, they do not identify the transmission phase that was used in the old SRNC (i.e., the current values of state variables, counters etc.). The target RNC cannot replicate the transmission phase completely in the Target RNC; however it can—because of L2 re-establishment—reset all UTRAN state variables and configuration parameters to their initial values. The most critical layer in this case is the RLC layer, which contains several status variables, configuration variables, timers and counters which are all increased/decreased upon active data transmission based, e.g., on the amount of data sent from the RLC layer and received status reports from the peer RLC entity. Therefore it is very important to achieve synchronization between the peer RLC entities before any data (signalling or user data) is sent either upon or after the SRNS relocation procedure. FIG. 5A shows an example of the RLC variables before initialization of the SRNS relocation where the variables are defined in 3G TS 25.322 at Section 9.4 (“State Variables”) as follows:
VT(S)—Send state variable—The sequence number of the next PU to be transmitted for the first time (i.e., excluding retransmission). It is updated after transmission of a PDU, which includes not earlier transmitted PUs and after transmission of a MRW SUFI. The initial value of this variable is 0.
VT(A)—Acknowledge state variable—The sequence number of the next in-sequence PU expected to be acknowledged, which forms the lower edge of the window of acceptable acknowledgements. The initial value of this variable is 0.
VT(MS)—Maximum Send state variable—The sequence number of the first PU not allowed by the peer receiver [i.e., the receiver will allow up to VT(MS)−1], VT(MS)=VT(A)+Tx_Window_Size. This value represents the upper edge of the transmit window. The transmitter shall not transmit a new PU if VT(S) VT(MS). VT(MS) is updated based on receipt of a STATUS PDU including an ACK and/or a WINDOW super-field.
VR(R)—Receive State variable—Receive State variable—The sequence number of the next in-sequence PU expected to be received. It is set equal to SNmax+1 upon receipt of the next in-sequence PU, where SNmax is the sequence number of the highest received in-sequence PU. The initial value of this variable is 0.
VR(H)—Highest expected state variable—The sequence number of the highest expected PU. This state variable is set equal to SN+1 only when a new PU is received with VR(MR)>SN≧VR(H). The initial value of this variable is 0.
VR(MR)—Maximum acceptable Receive state variable—The sequence number of the first PU not allowed by the receiver [i.e., the receiver will allow up to VR(MR)−1], VR(MR)=VR(R)+Rx_Window_Size. The receiver shall discard PUs with SN≧VR(MR).
FIG. 5B shows an example of the RLC variables after the reestablishment of the RLC entity in the target RNC. As can be seen by comparing FIG. 5A with 5B, the transmitting side can have its VT variables reset. This creates a difference between the RLC variables in the transmitting side (VT) and the receiving side (VR).
The situation is very critical if the synchronization is lost between such RLC entities, which are used for the transmission of the first RRC message, which informs the UE about the SRNS relocation that has occurred. If this message does not pass the RLC layer in the UE, because of the RLC synchronization problems, the SRNS relocation cannot be successful, and the worst case is that the whole RRC connection must be released with the consequent disruption of the exchange of control of the communication link. The RLC level synchronization must be maintained for the signalling RB (RB 2), which is used upon transmission of the first RRC message from UTRAN to UE. (Note: Depending on the network configuration the RRC message in question can be sent by using either the unacknowledged RLC entity=RB 1 or acknowledged RLC entity=RB 2 (see TSG RAN TS 25.331). In this specification the case where RB 2 is used is discussed at length).
Since it is impossible to predict beforehand the need for an SRNS relocation, it is also impossible to make any advance arrangements on L2 in the SRNC to support any forthcoming SRNS relocation procedure. This means that some form of re-synchronization of L2 is needed during or after the SRNS relocation.
The 3GPP TS 25.322 RLC specification defines for the RLC layer the RLC Reset procedure, which is used when the RLC detects an unrecoverable protocol error on the RLC layer. The RLC entity triggers the RLC reset in order to recover from an error situation and to resynchronize the peer RLC entities. This is done by resetting the state variables to their initial value and resetting the configurable parameters to their configured value on both peer RLC entities. After a successful RLC reset, the RLC entity can continue the interrupted data transmission. According to the current TSG RAN TS 25.322 RLC specification the RLC Reset procedure is initialized only when the RLC entity detects an error situation.